Prior art web Portals provide end users with unified access to content, applications, and collaboration services in a highly personalized manner. An example is IBM's WebSphere Portal which provides a middleware framework and tools for building and managing portals using component applications called portlets. A Web portal, or simply a portal, is a Web site that offers a broad array of resources and services typically targeted towards specific categories of user populations.
Although portlets can use Web services to implement their function, this requires a significant programming effort. The WSRP standard simplifies integration of remote applications and content into a portal via Web services without programming.
WSRP standardizes Web services at the presentation layer on top of the existing Web services stack, builds on the existing Web services standards, and will benefit from additional future Web services standards efforts as they become available.
At its core, the WSRP standard defines pluggable, user-facing, interactive Web services that implement Web Services Description Language (WSDL) interfaces and a fixed protocol for processing user interactions and providing presentation fragments suitable for mediation and aggregation by portals. WSRP defines the conventions for publishing, finding, and binding such services. WSRP permits any compliant Web service to be plugged into any compliant portal without requiring any service-specific adapters. A single, generic adapter on the portal end is sufficient.
FIG. 1 gives a schematic system view on a Web server implementing such prior art Web Portal.
A prior art Portal as e.g., represented by above IBM WebSphere Portal or by Jetspeed2 Enterprise Portal is built by a complex functionality implemented on a network server —for example a Web server 100, the most important elements of which are logic components for user authentication 105, state handling 110, aggregation 115 of fragments, a plurality of Portlets 120 —further described below-provided in respective pages 125 with a respective plurality of APIs 130 to a respective Portlet container software 135 for setting them into the common Web page context, and some Portal storage resources 140. The logic components are operatively connected such that data can be exchanged between single components as required. This is roughly depicted in FIG. 1.
In more detail, a Portal engine of the Web server in FIG. 1 implements an aggregation of Portlets 120 based on the underlying Portal model 150 and Portal information such as security settings, user roles, customization settings, and device capabilities. Within the rendered page, the Portal automatically generates the appropriate set of navigation elements based on the Portal model. The Portal engine invokes Portlets during the aggregation as required and when required and uses caching to reduce the number of requests made to Portlets. The prior art IBM WebSphere Portal employs open standards such as the Java Portlet API (application programming interface). It also supports the use of a remote Portlet via the WSRP standard.
Remote portlets are portlets, which reside on a different portal server and which are accessed through an appropriate web service protocol. An example is the before-mentioned WSRP 1.0. Due to this fact a remote portlet can be regarded and processed like a traditional web service itself. This is why also remote portlets can be referenced in a prior art service broker which provides business information and technical information about web services to any requesting web service consumer. In this sense, Web Services are implemented by respective Remote Portlets running on a Portal Server of the Service Provider.
As follows from www.uddi.org the so-called Universal Description, Discovery, and Integration (UDDI) protocol is a key member of the group of interrelated standards that comprise the Web services stack. It defines a prior art standard method for publishing and discovering the network-based software components of a service-oriented architecture (SOA). The current version is UDDI V3.02 and describes the Web services, data structures and behaviors of all instances of a UDDI registry.
FIG. 2 shows the general situation relevant for the present invention. A Service oriented architecture (prior art) is given in a networked environment, wherein a Service Broker 230 is requested by a Service Consumer 210 for offering Web Services, and a Service Provider 220 provides a requested Web Service to the Service Consumer. In the real world, of course, each of said objects 210, 220 and 230 are present multiple times.
Such Service-oriented architecture is for example described in IBM Systems Journal, Vol. 41, No. 2, 2002, pp 170 to 177.
FIG. 3 illustrates prior art interactions between Service Broker and Service Requester and Service Provider. More particularly, a prior art UDDI service broker 130 and a sample UDDI client—both, service requester and service provider may act as client—interact according to the following basic scheme:
The UDDI client 210, 220 incorporates a SOAP client and invokes UDDI operations through this SOAP client. The UDDI service broker 230 offers the UDDI web service interface and thus incorporates HTTP server and SOAP server components that receive the UDDI request issued by the UDDI client. The UDDI service broker further incorporates a component to process the UDDI request based on the service data which is stored in a Registry database. The SOAP server invokes this component which processes the request and returns the response to the UDDI client through the HTTP server.
FIG. 4 illustrates the prior art interactions between a service requester and a service provider via WSRP.
The Service Requester comprises a portal which is embedded in an application server. The Portal Server consumes a remote portlet via the standard WSRP protocol. For this purpose the service requester incorporates a WSRP client and a SOAP client component.
The service provider incorporates a SOAP server, a WSRP server and a portlet container. The WSRP server accepts the WSRP request and processes the requests by preparing and invoking an appropriate operation on the local portlet via the Portlet container. The request is processed and the resulting data is returned to the requester.
With reference to FIG. 5A the functional components structure of a prior art Service Broker comprises a HTTP Server 43, a SOAP Server 44, a Request processor 45, and a database 46 to store the Web Services identifications, and other commercial data related thereto. All components are provided with a hardware and/ or software interface as required to any other components.
The Request processor 45 processes the requests against its database 46. Incoming requests are processed and the resulting data is returned to a Service Requester. SOAP Server 44 as well as HTTP Server 43 implements the functionality required by the protocols, when using the Internet and the above-mentioned SOAP protocol.
With further reference to the very focus of the present invention prior art service brokers support search operations for searching web services which are based on keywords or on manual categorization. A prior art service broker, however, does not recognize the semantics or functional similarities or relationships between web services. The discovery of web services based on manually assigned keywords and categories which is supported by UDDI is inefficient, because the services retrieved by an UDDI search are often not corresponding to that what was expected in the search.
So the prior art search for Web Services has generally a low precision, i.e. many services are found which are not wanted by the client, and a low recall rate, i.e. the search misses the services which were really needed to be considered by the client.